Project Info - Leave No One Behind

Leave No One Behind is a puzzle game built by me and a team of my peers. I served as the team's programmer, gameplay designer, and level designer. This project will show how I am able to prepare for and work through the challenge and complexity of puzzle game design while making production smooth for both me and my teammates.

Gameplay

Main Takeaways

Puzzle design requires a great deal of experimentation! Be ready to spend hours combining mechanics together to try and make something interesting emerge.
Puzzle design requires a great deal of patience! Be ready to have to scrap or rework a puzzle because you did not take a certain interaction into account! Test a puzzle extensively before finalizing its art/geometry or create a system that makes these easy to edit.
Be lenient when introducing mechanics to players. The novelty of encountering a new mechanic can often be made exciting enough to stand on its own briefly.
The features added to a team project must be carefully considered; Most additions to a game require work from more than one team member. Levels also need to be lit by a lighting artist, character abilities require their own sounds and animations, and so on so forth.

Character Design

Puzzles in Leave No One Behind are solved by swapping between the game's three characters. Characters can be moved independently of one another and each has their own way of interacting with the world (think Lego Star Wars or the other Lego games).

Our team created three concepts for characters: From left to right are the Strongman, the Techie, and the Witch. As the gameplay designer, I took on the task of designing how each of the three characters would behave. I based the way each character would interact with the game off of the idea that part of what made puzzle games fun was the solution being just a little ambiguous. If it was too certain what arrangement of steps the player needed to complete a puzzle, then it would essentially be nothing more than a fancy tasklist for the player to complete.

In service of this idea, I created a baseline for how each character's abilities would be designed: Every character would have a couple of interactions which would be shared to some extent with one of the other two characters. For example, the Witch can jump up to higher areas like the Strongman, but can also press Switches like the Techie. To give each character their own unique identity and feel, characters all have abilities exclusive to them, such as the Witch's ability to not just jump but fly.

This all forms something of a matrix, which is shown below. Each intersection represents abilities which the two characters share. The cells where two of the same character intersect represent abilities unique to only them:

	Strongman	Techie	Witch
Strongman	Can pick up Heavy Crates and press Heavy Pressure Plates (this was never implemented).	Can pick up crates. Can cross anti-magic barriers.	Can jump up to higher areas (The Techie cannot jump!).
Techie	X	Can use Tech Panels. Can levitate crates to or from far away locations.	Can press switches.
Witch	X	X	Can reach most vertical spaces via flight.

In addition to these abilities, all three characters can activate pressure plates by standing on them so long as they can actually reach the location the pressure plate is at. This is the final piece to allow me to create ambiguity when designing puzzles, leading to fun scenarios in which players must figure out when a certain character is needed at a certain place.

Other interesting character design notes:

I made anti-magic barriers to make it easy to keep the Witch (who has unlimited flight) out of an area while still allowing the other two characters in.
Originally during the design phase, The Witch was the one who could levitate crates. This got moved over to The Techie since the Witch's flight already made her pretty powerful and I didn't want The Techie's only ability to be interacting with switches and computers.
I gave the Techie a bit of extra movement speed as a fun little quirk. During development, I liked to call his wheelchair the "Gucci Wheelchair". A bit of this personality even shows in the Techie's animations.

Tutorial Puzzles

A good portion of No One Left Behind's levels are Tutorial Puzzles dedicated toward teaching the player how the game works. When making these levels, I remembered hearing somewhere about Portal's tutorial and the subtle design choices it makes to ensure the players do not leave it confused about the mechanics. For instance the first puzzles force the player to move in and out of each portal so that the player does not think that only a single portal can be walked through.

My takeaway from this was to take nothing for granted in terms of player knowledge. Tutorial puzzles always show the mechanics they present in isolation, where the player can hardly do anything other than utilize the mechanic and observe its function. This way, the player is sure to be primed on the mechanic when they are later asked to think about it in a broader context. In the very first puzzle, there is only the Strongman, a pressure plate, and some platforms which can be jumped up to after the pressure plate is pressed. A simple area like this lets a new player get acclimated without overwhelming them with too many details to take in. Tutorial puzzles do not need to be very challenging as they can rely on the novelty of discovering and exploring a new mechanic.

Main Puzzle Design

Once a mechanic or set of mechanics have been introduced to the player, I place a more challenging Main Puzzle for the player to solve. These introduce no new mechanics and instead combine older ones to create novel or more complex situations for the player to solve through. From a design standpoint, these are much more difficult to design than the tutorial puzzles or even video game levels in general, as they often require the level to be arranged in a very precise way so that the puzzle cannot be "broken" by the player acting in an unexpected manner. I'll show off my process for working through this by going over the design of my favorite puzzle in the game: Sector 6.

This puzzle was made to serve as a capstone to the introduction of the anti-magic barrier mechanic. All the mechanics relevant in this puzzle are explained below:

Anti-Magic Barriers prevent the Witch from moving through them but allow all other characters pass. These can be disabled to let anybody through.
Crates can be picked up by the Strongman and Techie, but not the Witch.
The Witch can fly. The Strongman can jump a moderate height. The Techie cannot jump at all.
Pressure Plates can be pressed by having any character or a crate set on top of them.

Whenever I make a main puzzle, I start by either coming up with a solution that might be satisfying to uncover or coming up with an arrangement of puzzle pieces which I think would yield some interesting interactions. This gives me a framework with which to design the level around and narrows down my design space from the vague "Make a fun puzzle". As stated before, I had just introduced anti-magic barriers, so for Sector 6, I wanted a pressure plate blocked by an anti-magic barrier. During at least one moment of the puzzle, the Strongman or Techie would need to stand on the pressure plate, but later the player would need to lower the anti-magic barrier somehow and make the Witch stand on the pressure plate.

I then brainstormed different things this pressure plate could do. What I came up with was the pressure plate holding open a door to another room which any other character could enter: These always make interesting puzzles since the player must deal with being down a character in that particular space and are forced to stop and consider who needs to be in there and why. From here on out, this room will be called the Purple Room, after its purple doors which must be held open by a purple pressure plate. Now that I have the central framework of the puzzle and a decision point to make it interesting, I branch off from these ideas to put together a draft for the level.

To give a feeling of progression to a puzzle, I often make the very first steps to it obvious, such as performing a simple interaction that allows a crate to be spawned. This also helps to introduce the basic structure or gimmick of the puzzle. In Sector 6, I did this by making a window that allowed the Witch to fly into the Purple Room without its door being opened. From here the Witch can not only spawn the puzzle's crate, but also scout out what the other two pressure plates in the room do: The orange pressure plate, while pressed, disables the anti-magic barrier blocking the Witch from accessing the purple pressure plate. The red pressure plate holds open the level's exit. The Purple Door room has a transparent wall facing the rest of the level, so it is possible to observe these effects without switching characters, which is a lesser design goal I tend to strive for.

Once I have a level prototyped, I test through it to make sure the puzzle actually works and make edits so that there are no alternate solutions which break the puzzle. For instance, I raised the purple pressure plate high off the ground so that the Strongman needs the crate to reach it: Otherwise the crate could be grabbed by the Techie and used to open the exit while the Strongman holds the Purple Room open, meaning there's no need to lower the anti-magic barrier and let the Witch press the button like intended.

One final challenge I faced with this puzzle was realizing I may have made it impossible by accident: The Witch needed to stay on the purple pressure plate to let whoever opened the exit out of the Purple Room, but someone needed to be in the Purple Room to let the Witch back past the anti-magic barrier. The first thing I do in a situation like this is look for anything else I missed in the puzzle that would let me solve it anyway. In this case, if I had the Strongman open up the exit with the crate, he could climb the crate from here and use it to hop out of the window meant for the Witch to fly through (because the Purple Room is elevated, this technique can't be used by the Strongman to get into the room even though it works for leaving it). If I hadn't found this solution or any other one, searching for a way to solve an unsolvable puzzle would still give me ideas on what to add to make it solvable.

Overall, the name of the game when designing puzzles is patience. A great many hours has gone into brainstorming levels, toying with the mechanics to get new ideas, and making decisions on how the game as a whole would flow and introduce mechanics.

Enchantment Brewing

Early in Leave No One Behind's development, an idea for one of the Witch's abilities was floated around where she could brew potions for the other two characters to use. From this idea came the Enchantment Brewing mechanic, the final mechanic introduced to the player. Levels using this mechanic would have an ingredient placed somewhere that any character could collect by walking into it. Once collected, the player could open a menu to activate that ingredient's enchantment. Anytime thereafter, a player could have any character interact with a cauldron placed somewhere in the level to give that character the enchantment.

This mechanic comes with several quirks, which I included intentionally to make puzzles from. Firstly, while an enchantment is not consumed when given to a character, only one character may be enchanted at a time: If a new character uses the cauldron, the enchantment gets transferred from the old character to the new one. This is why the mechanic got renamed from potions to enchantments: Potions imply something consumable in most games and I didn't want the player to get confused!

Secondly, a character must actually be able to reach a cauldron to gain the enchantment: The menu only decides what enchantment the cauldron gives when interacted with. Finally, in case the player needs none of their characters to be enchanted, I made it so that an enchanted character has their enchantment cleared when interacting with a cauldron.

Due to time constraints, I found myself forced to pick from one of the four enchantment ideas I had created:

Extra jump height
Cloning the enchanted character
Flight
Walking through walls

I rejected the first idea simply because I did not think it was very exciting.

I really liked the second idea, but not only did I suspect it would take way too long to code properly and test a puzzle with, but that it was also liable to make a super complicated puzzle that might create a spike in difficulty given the game's short length.

Flight was my initial ability of choice out of the four options: It would be super quick to code since I simply had to port the functionality from the Witch to the other two characters. It was also interesting, since it would suddenly allow the Techie (who can't jump!) to reach high up areas or allow either him or the Strongman to bring crates anywhere the Witch (who can't grab crates) could reach with her flight. Since the player would also already be familiar with the Witch's flight, it would also be trivial to introduce. All of this said, in fact, I would probably rework the enchantment tutorial to introduce the Flight Enchantment first if I were to continue developing the game.

However, I ultimately decided to introduce walking through walls, which I named the Ghost Enchantment. It was flashy and cool, it was something players were unlikely to have seen in another game, and it was not projected to be hard at all to implement since it only required a new collision setting (in fact, the silhouette effect may have taken longer than the ability itself to program!).

I limited the walls ghosted characters could walk through to moving platforms so that the player couldn't simply walk out of the level and out of bounds. This also meant a new texture didn't have to be made for a specific type of wall meant for ghost characters. In addition, I made it so that enchanted characters could not move through anti-magic barriers, letting me limit where a ghosted character could traverse.

I finished off this feature by making particles spawn from the enchanted character so that the player can tell at a glance who they are.

Enchanted characters also have a silhouette when inside of an object so that the player can tell where they are. These silhouettes are color coded, so you can even tell which character is inside the wall!